<!DOCTYPE html>
<html lang="en" dir="ltr">
<head>
  <meta charset="utf-8" />
  <title>opencpn:opencpn_user_manual:options_setting:connections</title>
<meta name="generator" content="DokuWiki"/>
<meta name="robots" content="index,follow"/>
<meta name="keywords" content="opencpn,opencpn_user_manual,options_setting,connections"/>
<link rel="search" type="application/opensearchdescription+xml" href="../lib/exe/opensearch.html" title="OpenCPN Manuals"/>
<link rel="start" href="connections.html"/>
<link rel="contents" href="connections.html" title="Sitemap"/>
<link rel="alternate" type="application/rss+xml" title="Recent Changes" />
<link rel="alternate" type="application/rss+xml" title="Current namespace" />
<link rel="alternate" type="text/html" title="Plain HTML" href="connections.html"/>
<link rel="alternate" type="text/plain" title="Wiki Markup" href="connections.html"/>
<link rel="canonical" href="http://localhost/dokuwiki/doku.php?id=opencpn:opencpn_user_manual:options_setting:connections"/>
<link rel="stylesheet" type="text/css" href="../lib/exe/css.php.t.bootstrap3.css"/>
<!--[if gte IE 9]><!-->
<script type="text/javascript">/*<![CDATA[*/var NS='opencpn:opencpn_user_manual:options_setting';var JSINFO = {"id":"opencpn:opencpn_user_manual:options_setting:connections","namespace":"opencpn:opencpn_user_manual:options_setting","confirm_delete":"Are you sure you want to delete this page?","doku_base":"\/dokuwiki\/","cg_rev":"","dw_version":49.5,"chrome_version":0,"hide_captcha_error":"none","ckg_dbl_click":"","ckg_canonical":0,"has_wrap":"Wrap","wrapDiv":"WRAP","wrapSpan":"wrap","ckgEdPaste":"off","rel_links":0,"isadmin":0,"isauth":0,"move_renameokay":false,"schemes":["http","https","telnet","gopher","wais","ftp","ed2k","irc","ldap"],"htmlok":0};
/*!]]>*/</script>
<script type="text/javascript" charset="utf-8" src="../lib/exe/jquery.php.t.bootstrap3.js"></script>
<script type="text/javascript" charset="utf-8" src="../lib/exe/js.php.t.bootstrap3.js"></script>
<!--<![endif]-->

    <script type="text/javascript">
    //<![CDATA[ 
    function LoadScript( url )
    {
     document.write( '<scr' + 'ipt type="text/javascript" src="..//url"><\/scr' + 'ipt>' ) ;        

    }
   function LoadScriptDefer( url )
    {
     document.write( '<scr' + 'ipt type="text/javascript" src="..//url" defer><\/scr' + 'ipt>' ) ;        

    }
//]]> 

 </script>
</head>
<body>
<div class="dokuwiki export">



<h1 class="sectionedit1" id="the_connections">The Connections</h1>
<div class="level1">

<p>
<img src="../opencpn/manual/options-connection-icon.jpg" class="media" alt="" /></a>
</p>

<p>
<img src="../opencpn/manual/toolbar-options-connections-net-1.jpg" class="media" alt="" /></a>
</p>

<p>
<img src="../opencpn/manual/toolbar-options-connections-net-2.h.214_tok.6dfc04_w.552.jpg" class="media" alt="" width="552" height="214" /></a>
</p>

</div>
<!-- EDIT1 SECTION "The Connections" [20-225] -->
<h3 class="sectionedit2" id="features_and_improvements">Features and Improvements</h3>
<div class="level3">

<p>
NMEA Sentences moved to “Advanced Features”
</p>

<p>
OpenCPN version 3.2 featured a complete redesign of the NMEA message handling structure, including a new <abbr title="Graphical User Interface">GUI</abbr> and monitor window. This feature has been further improved and tuned in version 4.2. The current scheme provides extensive NMEA management capabilities, including:
</p>
<ul>
<li class="level1"><div class="li"> Input message filtering, by TALKER ID and/or message type.</div>
</li>
<li class="level1"><div class="li"> Implement configurable NMEA Talker ID.</div>
</li>
<li class="level1"><div class="li"> Virtually unlimited input port multiplexing, with shared I/O and individual data rate settings.</div>
</li>
<li class="level1"><div class="li"> Selective message echo capability, similar to third-party mux applications.</div>
</li>
<li class="level1"><div class="li"> Programmable output port messages, for e.g. autopilot interfaces.</div>
</li>
<li class="level1"><div class="li"> Full Network input and output, including TCP, UDP, and GPSD services.</div>
</li>
<li class="level1"><div class="li"> GPSD client support for Windows platforms.</div>
</li>
</ul>

</div>
<!-- EDIT2 SECTION "Features and Improvements" [226-1059] -->
<h3 class="sectionedit3" id="contents">Contents</h3>
<div class="level3">

<p>
<em><span class="curid"><a href="connections.html#linux_serial_connections" class="wikilink1" title="opencpn:opencpn_user_manual:options_setting:connections">Linux Serial Connections</a></span> <br/>

<span class="curid"><a href="connections.html#connections_window" class="wikilink1" title="opencpn:opencpn_user_manual:options_setting:connections">Connections Window</a></span> <br/>

<span class="curid"><a href="connections.html#example_data_connections_window" class="wikilink1" title="opencpn:opencpn_user_manual:options_setting:connections">Example Data Connections Window</a></span> <br/>

<span class="curid"><a href="connections.html#filter_nmea_course_and_speed_data" class="wikilink1" title="opencpn:opencpn_user_manual:options_setting:connections">Filter NMEA Course and Speed Data</a></span> <br/>

<span class="curid"><a href="connections.html#show_nmea_debug_window" class="wikilink1" title="opencpn:opencpn_user_manual:options_setting:connections">Show NMEA Debug Window</a></span> <br/>

<span class="curid"><a href="connections.html#data_connections_-_add_and_remove" class="wikilink1" title="opencpn:opencpn_user_manual:options_setting:connections">Data Connections - Add and Remove</a></span> <br/>

<span class="curid"><a href="connections.html#add_a_serial_connection" class="wikilink1" title="opencpn:opencpn_user_manual:options_setting:connections">Add a Serial Connection</a></span> <br/>

<span class="curid"><a href="connections.html#add_a_network_connection" class="wikilink1" title="opencpn:opencpn_user_manual:options_setting:connections">Add a Network Connection</a></span> <br/>

<span class="curid"><a href="connections.html#network_gpsd_connection" class="wikilink1" title="opencpn:opencpn_user_manual:options_setting:connections">Network GPSD connection</a></span> <br/>

<span class="curid"><a href="connections.html#connections_filter" class="wikilink1" title="opencpn:opencpn_user_manual:options_setting:connections">Connections Filter</a></span> <br/>

<span class="curid"><a href="connections.html#input_filtering" class="wikilink1" title="opencpn:opencpn_user_manual:options_setting:connections">Input Filtering</a></span> <br/>

<span class="curid"><a href="connections.html#output_filtering" class="wikilink1" title="opencpn:opencpn_user_manual:options_setting:connections">Output Filtering</a></span> <br/>

<span class="curid"><a href="connections.html#connection_notes" class="wikilink1" title="opencpn:opencpn_user_manual:options_setting:connections">Connection Notes</a></span> <br/>

<span class="curid"><a href="connections.html#sending_an_active_route_to_an_autopilot" class="wikilink1" title="opencpn:opencpn_user_manual:options_setting:connections">Sending an Active Route to an Autopilot</a></span> <br/>

<span class="curid"><a href="connections.html#sending_routes_and_waypoints_to_a_gps" class="wikilink1" title="opencpn:opencpn_user_manual:options_setting:connections">Sending Routes and Waypoints to a GPS</a></span> <br/>

<span class="curid"><a href="connections.html#broadcast_and_multicast" class="wikilink1" title="opencpn:opencpn_user_manual:options_setting:connections">Broadcast and Multicast</a></span></em><br/>

</p>

</div>
<!-- EDIT3 SECTION "Contents" [1060-2913] -->
<h3 class="sectionedit4" id="linux_serial_connections">Linux Serial Connections</h3>
<div class="level3">

<p>
Make sure that you belong to the “<code>dialout</code>” group. To find out, run the “<code>$groups</code>” command. If you&#039;re not in “<code>dialout</code>”, add yourself with the command “<code>$sudo usermod -a -G dialout $USER</code>”. Logout of your current session for group changes to take effect. Check this straight away, it will save you from frustration later on. If there is a problem connecting the GPS to a physical port, such as <code>/dev/ttyS0</code>, the reason is probably that you don&#039;t belong to “dialout”. OpenCPN will display a warning, once per session, if you try to configure a serial connection, or starts the program with an active serial connection, and don&#039;t belong to the right group.
</p>

<p>
<img src="../opencpn/manual/group.jpeg" class="media" title="group.jpeg" alt="group.jpeg" /></a>
</p>

<p>
Red Hat based Linux versions are using the “<code>uucp</code>” group. Check what applies to your version of Linux, by using the return from the command <code>stat -c %G `ls /dev/*|grep -m1 tty[A-Z,a-z][0]</code> If the return is “<code>root</code>”, upgrade to a contemporary Linux version.
</p>

</div>
<!-- EDIT4 SECTION "Linux Serial Connections" [2914-3914] -->
<h3 class="sectionedit5" id="connections_window">Connections Window</h3>
<div class="level3">

<p>
All this is different from the logic in earlier versions of OpenCPN. From version 3.2, there is no defined “autopilot” port. The autopilot is simply connected to any available output- enabled data-stream, and gets everything on the bus, subject to user specified output filtering. There is no specific “shared” AIS and GPS port, as all ports are shared.
</p>

<p>
<img src="../opencpn/manual/420optionconnections.tok.049a77_w.600.jpg" class="media" alt="" width="600" /><br/>

<img src="../opencpn/manual/421optionconnections.tok.847e64_w.600.jpg" class="media" alt="" width="600" />
</p>

<p>
The key point to keep in mind with this new setup is the complete orthogonality between message sources, message destinations, and transport media. All messages come and go from an internal “bus”, and all internal modules have access to all messages. Any message can be received, and possibly re-transmitted according to the configuration established. If the messages get onto the bus,
</p>

<p>
OpenCPN will do the right thing. For example, if it is an AIS message, the AIS module will get the message and act accordingly. Plugins also get all messages.
</p>

</div>
<!-- EDIT5 SECTION "Connections Window" [3915-4960] -->
<h3 class="sectionedit6" id="example_data_connections_window">Example Data Connections Window</h3>
<div class="level3">

<p>
<img src="../opencpn/manual/connections.tok.bb7b2a_w.600.jpg" class="media" alt="" width="600" />
</p>

<p>
To get a taste of what can be done, we start with a lab scenario. In the screen-shot above, four Data Ports are enabled.
</p>
<ul>
<li class="level1"><div class="li"> <strong>GPSD on localhost port 2947</strong></div>
</li>
<li class="level1"><div class="li"> <strong>/dev/ttyUSB1 as ais port</strong></div>
</li>
<li class="level1"><div class="li"> <strong>output port</strong> to a computer on the local network </div>
</li>
<li class="level1"><div class="li"> <strong>San Fransisco AIS</strong> feed.</div>
</li>
</ul>

<p>
<strong>Note that the connections are automatically sorted</strong> in order of the priority setting The picture is from a Linux computer, but the receiving box is an Win XP. Both boxes are configured to use the same broadcasting address &#039;192.168.0.255&#039; on the local network, using the default 10110 port. Note that <strong>UDP</strong>, and not TCP, is used. OpenCPN on the XP box receives and shows all info from the three first ports and even data from the VDR plugin, if it&#039;s running. <em>All input sources are merged together and available to transmit to an external computer. Every computer on-board can be used as a repeater to the main box!</em>
</p>

<p>
<strong>Note that in this scenario the UDP connection is output only</strong>. In previous releases of OpenCPN all UDP data connections would read data as well as write. This is a possible configuration in the current release but neither required nor generally desirable. If a broadcast connection is read/write, all data written will be read back leading to the potential for data loops.
</p>
<ul>
<li class="level1"><div class="li"> To avoid this, the priority of any read/write broadcast connection should be set lower than that of any other interface on which OpenCPN receives data for re-distribution over that interface.</div>
</li>
<li class="level1"><div class="li"> For most purposes <strong>setting a broadcast connection to either read or write is the preferable solution</strong>.</div>
</li>
<li class="level1"><div class="li"> The San Francisco AIS feed has now changed to ip address 76.103.90.196, also on port 9009.</div>
</li>
</ul>

<p>
There is no advantage to using a broadcast address on the local network with just a few computers. It&#039;s as easy to just specify the addresses of the receiving computers as outgoing connections on the transmitting computer. The “receivers” specify the “transmitter” as address for a connection.
</p>

<p>
In real life, <strong>a common setup</strong>  will include input from GPS, AIS and output to an Autopilot. If your GPS produces GPRMC, then this will be automatically shipped to the autopilot.
</p>
<ul>
<li class="level1"><div class="li"> Everything on the internal multiplex bus will be sent to the output port that the autopilot is connected to, even if a route is inactive.</div>
</li>
<li class="level1"><div class="li"> If, a route is active, OpenCPN will create and send NMEA (EC)RMC sentences to output data ports.</div>
</li>
<li class="level1"><div class="li"> The only reason OpenCPN “synthesize” an ECRMC sentence is to cover those odd cases when there is no other source of RMC in the system, and the Autopilot wants variation, SOG, etc. This might be the case if an older GPS produces GPGLL alone, for instance, which has no var. There is no “new” information in the transmitted, synthesized ECRMC.</div>
</li>
<li class="level1"><div class="li"> The autopilot might be complaining that it is getting RMC information from two different talkers (GP and EC) at the same time, and cannot decide what to do. The easiest solution if don&#039;t like the ECRMC, is to filter it out of the output stream of the port connected to the autopilot. Or choose a filter to allow only GPRMC and ECRMB for this port.</div>
</li>
</ul>

</div>
<!-- EDIT6 SECTION "Example Data Connections Window" [4961-8149] -->
<h3 class="sectionedit7" id="filter_nmea_course_and_speed_data">Filter NMEA Course and Speed Data</h3>
<div class="level3">

<p>
Providing a rolling average of COG/SOG, with configurable sampling period. This feature is useful, for example, if you find that course and speed from the gps is varying erratically due to the sea state. The Dashboard plugin is not affected by this setting - COG and SOG are updated about once per second.
</p>

<p>
<img src="../opencpn/manual/debug_win.tok.346225_w.600.jpg" class="media" alt="" width="600" />
</p>

</div>
<!-- EDIT7 SECTION "Filter NMEA Course and Speed Data" [8150-8546] -->
<h3 class="sectionedit8" id="show_nmea_debug_window">Show NMEA Debug Window</h3>
<div class="level3">

<p>
If you check this box you will get a window that shows the NMEA data sentences coming into or going out from OpenCPN. In the picture above we can see the color-coding at work. Messages in red could occur as well, and indicates a transmit error. Connections Priority change messages, will also be printed to the NMEA Debug Window. The reason that AIVDM messages are both dropped and appear as “Output message”, is that there is more than one source for this message, and the filter just applies to one source.
</p>

<p>
<strong>Have a look at the page NMEA Sentences</strong>  to see which messages are understood. OpenCPN generally does not care about the Talker ID, the first two letters in the message type. $GPGGA above, is the talker GP = the gps, sending a GGA = position message, for example. At the end of each sentence there is a “*” followed by a calculated checksum.
</p>

<p>
<em class="u"><strong>To see all messages</strong></em> it&#039;s important to close the Options dialog completely, while leaving the NMEA Debug window open. <em>The ECAPB sentences etc, will not appear while the Connections dialog box is open as autopilot output is disabled during this time.</em>
</p>

<p>
<em class="u"><strong>Known issues:</strong></em> The pause button only works if the main Options dialog is closed. In Linux, the debug window can only be closed by unticking the <em>Show NMEA Debug Window</em>  box, unless the the main <strong>Options</strong>  dialog is closed.
</p>

<p>
If there are NMEA sentences in the debug window, then OpenCPN has opened the port set in the Data Connections. Note that the source of each NMEA sentence is printed after the time stamp o each line. If your GPS port is configured, and there is no “red” boat, then the only reasons are: no gps fix or wrong sentence configuration from the GPS.
</p>

<p>
Messages originating from <strong>GPSD</strong>  or the VDR (Voyage Data Recorder plugin) will also show up in the debug window.
</p>

<p>
<strong>For simple NMEA data stream debugging</strong>, add the following to your <strong>opencpn.ini</strong>  file:Under <em>[Settings]</em>  add a line <em>DebugNMEA=1500</em>  This will provide up to 1500 debug messages pertaining to NMEA traffic to the <em>opencpn.log</em>.
</p>

<p>
<strong>Format uploads for FurunoGP3Xinputfiltering</strong>: If the special Furuno gps protocol is needed, tick this box. The reason is that Furuno uses their own version of NMEA for uploading routes. Furuno GPS users take note. It is now allowed to use a numeric, two digit OpenCPN route name (e.g. 10, 21, etc).
</p>

<p>
Use GarminGRMN (Host) mode for uploads. Make sure that this box is ticked, if you have a Garmin GPS. The reason for this is that Garmin units cannot accept route uploads via standard NMEA0183. This is a “design feature” of all Garmin receivers.
</p>

<p>
Use magnetic bearings in output sentence ECAPB. Some autopilots, among them Simrad, require navigational bearings, contained in the APB sentence, to be transmitted as Magnetic bearings rather than as True bearings, OpenCPNs default.
</p>

</div>
<!-- EDIT8 SECTION "Show NMEA Debug Window" [8547-11418] -->
<h3 class="sectionedit9" id="data_connections_-_add_and_remove">Data Connections - Add and Remove</h3>
<div class="level3">

<p>
Two Buttons “Add Connections” and “Remove Connections”, to the right of the Connections window are the key to this whole tab.
</p>

<p>
The enable choice at the start of each connection line, is handy to organize connections, but still only use those that are needed for the moment. Tick or un-tick, and then press “Apply”, to activate the setting.
</p>

<p>
A connection can be used for input and output at the same time, with the reservation that they have to use the same Baud rate. For more details, read on.
</p>

<p>
When pressing “Add Connections” two basic choices are given, a serial or a network connection.
</p>

</div>
<!-- EDIT9 SECTION "Data Connections - Add and Remove" [11419-12055] -->
<h3 class="sectionedit10" id="add_a_serial_connection">Add a Serial Connection</h3>
<div class="level3">

<p>
<img src="../opencpn/manual/42addserialconnection.tok.005afa_w.600.jpg" class="media" alt="" width="600" />
</p>

<p>
<strong>DataPort</strong>: Pick a port by pressing the \/ o the right side of the field. If the port you are looking for does not appear in the selection, write the correct port yourself in this field.
</p>

<p>
<strong>Baud Rate</strong>: This is normally 4800 for GPS and 38400 for AIS, but check the documentation for the connected device. It&#039;s important to get this right and not just guess.
</p>

<p>
<strong>Protocol</strong>: For future use, as only NMEA 0183 works, for now.
</p>

<p>
<strong>Priority</strong>: Higher number equals Higher priority. The priority is set for each NMEA sentence individually. As long as a higher priority stream is available it&#039;s used. If this fails the next stream in line, with lower priority, kicks in and is used, until a higher priority stream appears. The present filter does not handle the case where, for example position messages, are received from different sentences.As an example, GPGLL and GPRMC both transmits the position information. The last received of either message will be used.
</p>

<p>
<strong>Control Checksum</strong>. At the end of each NMEA sentence is a checksum, that makes sure that sentences are correctly received. This box is ticked by default, as OpenCPN calculates the checksum and compares it to the received checksum. Only sentences with a valid checksum are passed through. Un-ticking may help, if an application calculates checksums incorrectly or if the checksums are missing.
</p>

<p>
Use <strong>Garmin(GRMN)</strong>  mode for input: Make sure that this box is ticked, if you have a Garmin GPS set to this mode. The reason is that Garmin uses their own serial protocol.
</p>

<p>
<strong>Receive input</strong>  on this Port Greyed out here as it only applies to a network connection. see more below.
</p>

<p>
<strong>Output on this port</strong>  (as Autopilot or NMEA repeater ): Tick this box if the connection will be used for output. A common case is sending NMEA to an Autopilot. * Talker ID solves the problem where some “temperamental” devices, which should accept given sentences irrespective of the talker ID, in fact only accept for example GPRMC and not ECRMC
</p>

<p>
<strong>APB bearing precision</strong>  is greyed out unless “Output on this port” is checked. APB is the NMEA sentence “Autopilot Sentence &#039;B&#039;”. The precision can be set to between 0 and 4 decimals, were 3 is the default. Some autopilots requires a different precision than the default, to work. Check your AP documentation.
</p>
<ul>
<li class="level1 node"><div class="li"> Note: The <strong>APB bearing precision</strong>  (or NMEAAPBPrecision in Opencpn.ini file) setting is set in the Options &gt; Connections settings page for connections that have outgoing messages. The precision is applied in the src/nmea0183/ apb.cpp file and is applied to:</div>
<ul>
<li class="level3"><div class="li"> CrossTrackErrorMagnitude</div>
</li>
<li class="level3"><div class="li"> BearingOriginToDestination</div>
</li>
<li class="level3"><div class="li"> BearingPresentPositionToDestination</div>
</li>
<li class="level3"><div class="li"> HeadingToSteer</div>
</li>
</ul>
</li>
<li class="level1"><div class="li"> This change was made as some auto pilots are limited in the precision they can accept in the APB message. So all other messages and internally the precision is not changed. There is no change to the XTE message as that was not requested at the time. “XTE - Measured cross track error” NMEA message, that is a part of the APB message is not adjusted by the APB bearing precision setting.</div>
</li>
</ul>

</div>
<!-- EDIT10 SECTION "Add a Serial Connection" [12056-15243] -->
<h3 class="sectionedit11" id="add_a_network_connection">Add a Network Connection</h3>
<div class="level3">

<p>
<img src="../opencpn/manual/options-connections-network_0.tok.e29212_w.600.jpg" class="media" alt="" width="600" />
</p>

</div>

<h4 id="protocolthere_are_three_choices_of_protocols_tcp_udp_and_gpsd">Protocol : There are three choices of protocols **TCP**, **UDP** and **GPSD**.</h4>
<div class="level4">

<p>
<strong>TCP</strong>: is a “connection-oriented” protocol which provides a reliable link between two network endpoints. TCP ensures that any network packets lost in transit are re-transmitted. Internet AIS servers normally accept TCP connections as do many serial-to-network/wifi devices.
</p>

<p>
<strong>To make a connection to a remote TCP server</strong>, enter its <em>IP address</em>  or <em>hostname</em>  in the “<strong>Address</strong>” box and the TCP port on which the server listens in the “DataPort” box. Many devices use a non-standard TCP port rather than OpenCPN&#039;s standard 10110, so do check the server&#039;s documentation. If “<strong>0.0.0.0</strong>” is entered in the <strong>Address</strong>  box, OpenCPN will act as a <strong>TCP server</strong>  accepting a connection from a <strong>remote TCP client</strong>. OpenCPN will <strong>listen</strong>  on all its host computer&#039;s network interfaces for <strong>TCP connections</strong>  to the port specified in the “<strong>DataPort</strong>” field. There should normally be no reason to select a “<strong>DataPort</strong>” value other than the <strong>standard 10110</strong>  unless multiple servers are required:
</p>
<ul>
<li class="level1"><div class="li"> In the current implementation a single data connection can accept only one client.</div>
</li>
<li class="level1"><div class="li"> If multiple clients wish to connect to OpenCPN, a dedicated data connection must be provided for each and each data connection must have a different DataPort.</div>
</li>
</ul>

<p>
<strong>UDP</strong>: is a method of transmitting data as simple “<strong>datagrams</strong>” without negotiating a connection between two endpoints. It involves <em>no detection and retransmission of data lost in the network</em>. Within a small home/boat network such data loss should not normally occur and in any case, NMEA data is generally updated by “talkers” on a regular basis. <em>Unlike TCP which involves a connection between two endpoints, UDP data may be received by many “listeners”.</em>
</p>

<p>
An<strong> OpenCPN UDP data connection</strong>  will listen for data destined for the <strong>specified DataPort</strong>  on any system interface or the broadcast address of any connected network. If you don&#039;t need to receive multicast data or transmit any data, you may<em> enter “<strong>0.0.0.0</strong>” in the “Address” box</em>  if you are unsure of what to enter there. Alternatively you may specify the address on which you <em>intend to receive data</em>. In both cases behavior will be the same. If you wish to receive multicast data you must enter the multicast address to which those data are being sent or the system will not see them. If you wish to transmit any data (“<strong>Output on this port</strong>” checked) you must <em>put the address you wish to send data to in the “Address” box</em>. In all cases (transmit, receive or both) the DataPort must be specified. For more information about broadcast and multicast, see Broadcast and Multicast below.
</p>

<p>
<strong>GPSD</strong>: is a Unix/Linux gps server, which means that several different applications can share one gps receiver. Linux users have the choice between using serial or GPSD connections for their gps input.
</p>
<ul>
<li class="level1"><div class="li"> <strong>Ubuntu users take note!</strong>  If gpsd is installed - use it. If you prefer a serial connection, un-install gpsd. The reason is that gpsd starts automatically when,for example, an USB gps is connected. This will block the serial port that the gps communicates with( /dev/ttyUSB0 in many cases), hence no separate serial connection to the gps is possible. So it&#039;s an either or situation.</div>
</li>
<li class="level1"><div class="li"> <strong>OpenCPN also has support for Windows clients.</strong>  So a windows computer should be able to connect to GPSD running somewhere on a network (testing), as an alternative to an UDP connection, described earlier. * Address: The network address to connect to. In the example above we used the broadcast address for convenience, but specifying host to send to, and host to receive from, works as well.</div>
</li>
</ul>

<p>
<strong>Port</strong>: The port to connect to on the network address. The default port for UDP is 10110. Port 10110 is designated by IANA for “NMEA-0183 Navigational Data”. There should not be any reason to change this port, but it is possible. See below. The default port for GPSD is 2947. Do not change this!
</p>
<ul>
<li class="level1"><div class="li"> For your own local connections use port-numbers greater than 1023 and avoid ports used by other applications. <em>Ports in the range 49152 through 65535 are not assigned to other applications and should be OK</em>. Make sure that no firewall is blocking the port you pick.</div>
</li>
</ul>

</div>
<!-- EDIT11 SECTION "Add a Network Connection" [15244-19639] -->
<h3 class="sectionedit12" id="network_gpsd_connection">Network GPSD connection</h3>
<div class="level3">

<p>
<img src="../opencpn/manual/gpsd-con1.tok.23e4c3_w.600.jpg" class="media" alt="" width="600" />
</p>

<p>
When connecting to GPSD, running on your local computer, use the settings shown above.
</p>

</div>
<!-- EDIT12 SECTION "Network GPSD connection" [19640-19807] -->
<h3 class="sectionedit13" id="connections_filter">Connections Filter</h3>
<div class="level3">

<p>
For each source line in the data connection windows, it&#039;s possible to specify exactly which NMEA sentences to receive, and which ones to drop. Similarly it&#039;s possible to control exactly which sentences to send out to, for example, an autopilot.
</p>

<p>
The applied filters for each connection are stated in in the “Filters” column in the Data Connection window. The default for a connection is no filters at all. * The set filters applies to both the core program and the plugins.
</p>

<p>
Filtering can be observed in real time, through color coding in the Debug Window.
</p>

<p>
<img src="../opencpn/manual/filtering.jpg" class="media" alt="" />
</p>

<p>
<strong>Accept only sentences</strong>: Either base your filtering on stating which sentences to accept or which to ignore. 
</p>

<p>
<strong>Ignore sentences</strong>: Same as above. To select filters press the button. The dialog below becomes available.
</p>

<p>
<img src="../opencpn/manual/sentence-filters.h.420_tok.6aec81_w.280.jpg" class="media" alt="" width="280" height="420" />
</p>

<p>
A lot of NMEA sentences are listed. Just tick the box to select a sentence. “Select All” or “Clear All” are also available. For sentences not listed press “Add”, and enter a new NMEA sentence.
</p>

<p>
<img src="../opencpn/manual/sentence-filters1.h.97_tok.c6cc1f_w.313.jpg" class="media" alt="" width="313" height="97" />
</p>

<p>
Your entry must conform to these rules.
</p>

<p>
<img src="../opencpn/manual/sentence-filters2.h.166_tok.9b5d51_w.459.jpg" class="media" alt="" width="459" height="166" />
</p>

<p>
When you are finished, press “OK”, your new entry will appear at the bottom of the list of NMEA sentences to filter. It will already be ticked, so just press “OK” until you are back in the original Connections tab. Now press “Apply”. The implemented filtering should now be visible on the connection line. For more, see below
</p>

<p>
<strong>Receive input on this port</strong>: This box should be ticked if you want to receive receive data on this connection. If the connection will only be used to output to other devices it should not be ticked. If you wish to broadcast UDP data for consumption by other devices or programs, leaving this box unticked will save you having to worry setting the priority of the connection to avoid data loops.
</p>

<p>
<strong>Output on this port</strong>  (as Autopilot or NMEA repeater ): Tick this box if the connection will be used for output. A common case is sending NMEA to an Autopilot. * APB bearing precision is greyed out unless “Output on this port” is checked. APB is the NMEA sentence “Autopilot Sentence &#039;B&#039;”. The precision can be set to between 0 and 4 decimals, were 3 is the default. Some autopilots requires a different precision than the default, to work. Check your AP documentation and see Note below.
</p>

<p>
OpenCPN creates and sends the NMEA ECRMB and ECRMC sentences to the A/P output port when a route is activated. If variation is not otherwise present, OpenCPN includes variation, coming from the WMM plugin, if installed and enabled.
</p>

<p>
Note: The “APB bearing precision” (or NMEAAPBPrecision in Opencpn.ini file) setting is set in the Connections settings page for connections that have outgoing messages. The precision is applied in the src/nmea0183/ apb.cpp file and is applied to:
</p>
<ul>
<li class="level1"><div class="li"> CrossTrackErrorMagnitude</div>
</li>
<li class="level1"><div class="li"> BearingOriginToDestination</div>
</li>
<li class="level1"><div class="li"> BearingPresentPositionToDestination</div>
</li>
<li class="level1"><div class="li"> HeadingToSteer</div>
</li>
<li class="level1"><div class="li"> This change was made as some auto pilots are limited in the precision they can accept in the APB message. So all other messages and internally the precision is not changed. There is no change to the XTE message as that was not requested at the time. “XTE - Measured cross track error” NMEA message, that is a part of the APB message is not adjusted by the APB bearing precision setting.</div>
</li>
</ul>

<p>
{{opencpn:manual:action-filter.jpg?nolink&amp;28x30}}
</p>

</div>
<!-- EDIT13 SECTION "Connections Filter" [19808-23335] -->
<h3 class="sectionedit14" id="input_filtering">Input Filtering</h3>
<div class="level3">

<p>
Some examples to illustrate how things works.
</p>

<p>
<img src="../opencpn/manual/in1.h.89_tok.304960_w.600.jpg" class="media" alt="" width="600" height="89" />
</p>

<p>
Accepting the filter above leads to this in the filter column on the connection line:
</p>

<p>
<img src="../opencpn/manual/in11.h.21_tok.9a67af_w.217.jpg" class="media" alt="" width="217" height="21" />
</p>

<p>
<img src="../opencpn/manual/in2.h.93_tok.c417ba_w.600.jpg" class="media" alt="" width="600" height="93" /> <br/>
If “Ignore sentences” is marked instead, the line looks like this: <br/>
<img src="../opencpn/manual/in22.h.21_tok.abacca_w.230.jpg" class="media" alt="" width="230" height="21" />
</p>

</div>
<!-- EDIT14 SECTION "Input Filtering" [23336-23738] -->
<h3 class="sectionedit15" id="output_filtering">Output Filtering</h3>
<div class="level3">

<p>
Similar to input filtering above.<br/>

<img src="../opencpn/manual/in2.h.95_tok.2f8a23_w.614.jpg" class="media" alt="" width="614" height="95" />
</p>

<p>
Transmitting three sentences.<br/>

<img src="../opencpn/manual/out22.h.23_tok.fabe2a_w.234.jpg" class="media" alt="" width="234" height="23" />
</p>

<p>
Another Example of Output Filtering<br/>

<img src="../opencpn/manual/connections-output-filter-sentence.jpg" class="media" alt="" /><br/>

<strong>Feature:</strong> Can now select the NMEA talker ID of sentences output by OpenCPN on a given port.
</p>

<p>
<strong>Situation:</strong> OpenCPN (correctly) outputs its NMEA sentences with the “EC” talker ID as is normal and expected behavior (see below).
</p>

<p>
<strong>Problem :</strong> Some “temperamental” devices which should accept given sentences irrespective of the talker ID in fact only accept for example GPRMC and not ECRMC.
</p>

<p>
<strong>Example:</strong> An Icom VHF is a such example. and because the multiplexer has been set to give precedence to nav info provided by OpenCPN, rather than the GPS, the result is that when OpenCPN is driving the autopilot, the VHF does not receive any position anymore for its DSC feature. Safety-wise, this is not desirable.
</p>

<p>
<strong>Solution:</strong> Being able to either change the ECRMC sentences into GPRMC, or duplicate ECRMC on the output port should solve the issue.
</p>

</div>

<h4 id="send_to_gps">Send to GPS</h4>
<div class="level4">

<p>
<img src="../opencpn/manual/out11.h.97_tok.7a572f_w.600.jpg" class="media" alt="" width="600" height="97" /><br/>

Dropping them instead.
</p>

<p>
<img src="../opencpn/manual/out12.h.25_tok.26c76a_w.247.jpg" class="media" alt="" width="247" height="25" />
</p>

</div>
<!-- EDIT15 SECTION "Output Filtering" [23739-25011] -->
<h3 class="sectionedit16" id="connection_notes">Connection Notes</h3>
<div class="level3">

<p>
<strong>If you already have an application connected to your gps, on a serial port, OpenCPN will not be able to connect to the same port.</strong> Two applications cannot use a port simultaneously . __On Linux use Gpsd in such a situation. Of course this only works if your “other application” supports the Gpsd. As an alternative on Linux you can use Kplex (also for Mac) or Muplex which can create pseudo terminals (“virtual serial ports”) to share NMEA data between applications.
</p>

<p>
If a NMEA sentence is filtered on an input connection and “LegacyInputCOMPortFilterBehaviour=1” setting in opencpn.conf|ini, it will still enter the internal multiplexer. So, it will be available to output connections, unless it&#039;s filtered there as well. If “LegacyInputCOMPortFilterBehaviour=0” then the message will not be placed on the internal multiplexer. This will only work for serial connections. Echoing back a network connection, on the input port for output, will not work
</p>
<ul>
<li class="level1"><div class="li"> NMEA data can also come from the VDR plugin. They will be labeled as such in the Debug Window and have “0” priority.</div>
</li>
</ul>

<p>
<strong>No Flow Control on Serial Ports</strong>  By nature NMEA doesn&#039;t do flow control. If a message gets lost, it gets lost… It will be repeated at some point, and buffering a delayed message that has lost it&#039;s meaning, when there is more current &amp; accurate data available is not useful. f interfacing the NMEA-specified way, there is no path for hardware flow control. It&#039;s not compatible with NMEA in any way.
</p>

</div>
<!-- EDIT16 SECTION "Connection Notes" [25012-26523] -->
<h3 class="sectionedit17" id="sending_an_active_route_to_an_autopilot">Sending an Active Route to an Autopilot</h3>
<div class="level3">

<p>
<strong>Autopilot APB</strong>  and <strong>XTE precision</strong>  settings are harmonized to always be the same.
</p>

<p>
On <strong>Route activation</strong>, OpenCPN sends the ECRMB, ECRMC and ECAPB NMEA sentences to an Auto Pilot, if it is connected to a port, with output activated.
</p>
<ul>
<li class="level1"><div class="li"> Implement configurable NMEA Talker ID</div>
</li>
<li class="level1"><div class="li"> To test that the ECRMB, ECRMC &amp; ECAPB sentences are being sent, simply set up a port with output activated and</div>
</li>
</ul>

<p>
<em>Right-click</em> on the chart and select “<strong>Navigate to here</strong>”, then bring up the <strong>Options &gt; Connections &gt; Nmea Debug</strong> window and look at the Blue output sentences for ECRMB, ECRMC and ECAPB. Below is one example of output connection settings.
</p>

<p>
<img src="../opencpn/manual/output-test-sm.h.566_tok.6ff2b7_w.500.jpeg" class="media" title="output-test-sm.jpg" alt="output-test-sm.jpg" width="500" height="566" />
</p>

<p>
In the example above we have used NavMonPC to read a previously recorded nmea file, and then set up a Virtual Com Port (Com14) which <strong>OpenCPN Options &gt; Connections</strong> to a Serial <strong>Com14 port</strong> is then established to read the nmea data stream from NavMonPC.
</p>

<p>
When you <strong>send to the autopilot</strong> you should see <strong>blue output sentences in the Nmea Debug window</strong>, <strong>once the Options Menu is closed</strong> (very important, because all data is frozen until this menu is closed.) * Another way to test for the EC sentences see “<strong>Send to GPS</strong>” below.
</p>

</div>
<!-- EDIT17 SECTION "Sending an Active Route to an Autopilot" [26524-27818] -->
<h3 class="sectionedit18" id="broadcast_and_multicast">Broadcast and Multicast</h3>
<div class="level3">

<p>
<strong>UDP data</strong> may be delivered to more than one system when sent to certain special addresses
</p>

<p>
<strong>A “broadcast address” is listened to by all devices on a network.</strong> It is normally formed by taking the network address (the first part of the IP address common to all systems on your local network) and setting the last part (the number which is different for every computer) to a value represented by all “1”s in binary. If all your devices&#039; addresses start with “192.168.1”, your network&#039;s broadcast address will likely be 192.168.1.255 (255 is “11111111” in binary. This is why IPv4 addresses written like this never contain numbers higher than 255. Except for in the movie “The Net” and we don&#039;t talk about that). If you specify an address ending with “255”, OpenCPN assumes you mean a broadcast address. This is not always true but will result in desired behaviour in almost all cases.
</p>

<p>
<strong>The special broadcast address “255.255.255.255” is also listened to by all devices.</strong> It should not normally be used to transmit data from OpenCPN. Use your local network&#039;s broadcast address instead.
</p>

<p>
<strong>A “multicast address” is listened to only by devices which wish to receive information on that address.</strong> IPv4 addresses in the range 224.0.0.0 - 239.255.255.255 are multicast addresses. If you specify a multicast address for a UDP data connection, OpenCPN will tell your computer to listen for datagrams on that address. * More than one system may send data to broadcast or multicast addresses, so this is a “many to many” communications medium. * You cannot use broadcast or multicast addresses with TCP. TCP is a “one to one” connection.
</p>

<p>
<strong>Devices must to some extent process all broadcast packets on the network whether they are interested in them or not.</strong> Multicast packets are normally only seen by devices which have registered an interest in a particular multicast address. Consequently multicast is more efficient than broadcast although this is usually of little consequence in a small network. Despite being used by NMEA-over-IP protocols such as IEC 61162-4 and the forthcoming NMEA OneNet, NMEA-0183 over IP multicast is far less widely supported in marine applications than NMEA-0183 over IP broadcast.
</p>

<p>
<strong>There is no multicast address mandated for NMEA-0183 data in this context</strong> although you should avoid those addresses used by other protocols. 
</p>

<p>
<strong>When using multicast with OpenCPN it is suggested</strong> that an address be used in the range 239.192.0.0/14 specified by <abbr title="Request for Comments">RFC</abbr> 2365 as the “Organization Local Scope”. If in doubt, try 239.194.4.4. 
</p>

<p>
<strong>There is no mechanism in OpenCPN to specify the network interface through which multicast packets are sent or received.</strong> This will be determined by your system. In some cases it may be necessary to manually adjust your system&#039;s routing table to ensure that the desired network interface is used. Refer to your system&#039;s documentation if this proves necessary.
</p>

<p>
<strong>If you transmit UDP broadcast or multicast, then you should set the priority of the “real” NMEA input to something higher than the UDP stream.</strong> If not, prepare for problems. The reason is that if you are broadcasting, then you yourself will get the UDP message as well, which again will be retransmitted…… Obviously, it duplicates the “real” incoming data. Thus we get source priority flip-flop on each message, since they have the same priority. For example set the UDP priority to “0” and real incoming connection to “1” or higher. Multicast loopback is not disabled for consistency with broadcast behaviour. This means that priorities must be set as detailed above when transmitting over multicast, but multicast communication between multiple instances of OpenCPN on the same system remains possible. * The firewalls on some systems (e.g. OpenSuSE linux) may block broadcast and multicast data that you wish to receive. Refer to your system&#039;s documentation to determine how to allow such data to reach OpenCPN.
</p>

<p>
Also read about the “<strong>Activating Routes and Active Route Console</strong>” in <strong>Marks and Routes</strong> towards the bottom. <em>It is essential to have turned on an Active Route in order to send waypoints to the Autopilot.</em>
</p>

<p>
Also read about “<strong>Route to Autopilot</strong>” in <strong>Advanced Features</strong> for more details.
</p>

</div>
<!-- EDIT18 SECTION "Broadcast and Multicast" [27819-32092] -->
<h3 class="sectionedit19" id="sending_routes_and_waypoints_to_a_gps">Sending Routes and Waypoints to a GPS</h3>
<div class="level3">

<p>
The feature “Send to GPS”, which appears in the right click menus for waypoints and routes and in the Route Manager, is not linked to connections. The upload port does not even need to appear in the Datastream connections list. Its a completely separate concept. For this reason users must define a separate upload port, that is remembered by OpenCPN. The port can be changed by clicking the button in the Route Manager.
</p>

<p>
NMEA provides no handshake protocol for Route and Waypoint upload. So, OpenCPN simply sends the Route/WP information out on the port, without having any way to know if there is actually a device connected to the port.
</p>

<p>
The Garmin protocol does provide handshaking, so OpenCPN can be sure that the information is uploaded correctly. The Garmin protocol will fail if the device is not a Garmin.
</p>

<p>
In the case of standard NMEA, the indication “Route successfully uploaded” is not very meaningful. You can say that it just means that a port was found, and writing to that port succeeded.
</p>

<p>
In the case of “hockey puck” GPS receivers, they probably ignore Route and WP uploads, since there is nothing for them to do with this information anyway.
</p>

<p>
The key to remember is that Route and Waypoint upload process is completely independent of normal running Datastream operation. They are two separate sub-systems.
</p>

<p>
It does no harm to assign the Datastream GPS port as an output and input device together. Some users might reasonably expect that this would be required for Route and W/P uploads. Most GPS receivers would ignore input sentences other than Route and W/P uploads anyway.
</p>

<p>
Then in the Chart window we hover over the temporary goto waypoint and right click, then select “Send to GPS (Serial Com 14)” and by quickly looking at the NMEA Debug window (Options &gt; Connections &gt; Check Nmea Debug Window, then be sure to CLOSE the Connections Menu leaving the Nmea Debug Window up, or nothing will happen!). Then you will see the sentences sent. See screenshot below.
</p>

<p>
<img src="../opencpn/manual/autopilot-output-sentences.h.351_tok.93f149_w.567.jpeg" class="media" title="autopilot-output-sentences.jpg" alt="autopilot-output-sentences.jpg" width="567" height="351" />
</p>
<ul>
<li class="level1"><div class="li"> Note the active route above was a 4 point route, but the active leg and active wp was the 3rd point for the above screen.</div>
</li>
</ul>

<p>
<img src="../opencpn/manual/activeroute-sent2gps-2.h.310_tok.19b3f9_w.559.jpeg" class="media" title="activeroute-sent2gps-2.jpg" alt="activeroute-sent2gps-2.jpg" width="559" height="310" />
</p>
<ul>
<li class="level1"><div class="li"> Note the screenshot above is for the same Active Route, but the active waypoint is the 2nd point.</div>
</li>
<li class="level1"><div class="li"> Note: There are many technigues for testing and simulation. Using NavMonPC to read a previously recorded file is one very good way. The other is to use OpenCPN&#039;s VDR_pi to read the nmea file, which is in some respects simpler for a new user.</div>
</li>
</ul>

</div>
<!-- EDIT19 SECTION "Sending Routes and Waypoints to a GPS" [32093-34729] -->
<h3 class="sectionedit20" id="notes">NOTES</h3>
<div class="level3">

</div>

<h4 id="win_81_com_ports_stop_working">Win 8.1 com ports stop working</h4>
<div class="level4">

<p>
Refer to <a href="http://willkamp.com/opencpn/flyspray/index.php?do=details&amp;task_id=1706" class="urlextern" title="http://willkamp.com/opencpn/flyspray/index.php?do=details&amp;task_id=1706" rel="nofollow">http://willkamp.com/opencpn/flyspray/index.php?do=details&amp;task_id=1706</a> Check the cables and connectors and for USB Port timeout. How to Add or Remove “USB 3 Link Power Mangement” in Power Options in Windows 8 <a href="http://www.eightforums.com/tutorials/50276-power-options-add-remove-usb-3-link-power-mangement.html" class="urlextern" title="http://www.eightforums.com/tutorials/50276-power-options-add-remove-usb-3-link-power-mangement.html" rel="nofollow">http://www.eightforums.com/tutorials/50276-power-options-add-remove-usb-3-link-power-mangement.html</a> <a href="http://helpdeskgeek.com/windows-xp-tips/prevent-windows-from-powering-off-usb-device/" class="urlextern" title="http://helpdeskgeek.com/windows-xp-tips/prevent-windows-from-powering-off-usb-device/" rel="nofollow">http://helpdeskgeek.com/windows-xp-tips/prevent-windows-from-powering-off-usb-device/</a>
</p>

</div>

<h4 id="udp_protocol_vs_tcp_protocol">UDP Protocol vs TCP Protocol</h4>
<div class="level4">

<p>
UDP is a method of transmitting data as simple “datagrams” without negotiating a connection between two endpoints. It involves no detection and retransmission of data lost in the network. Within a small home/boat network such data loss should not normally occur and in any case, NMEA data is generally updated by “talkers” on a regular basis. Unlike TCP which involves a connection between two endpoints, UDP data may be received by many “listeners”.
</p>

<p>
<strong>UDP</strong>  “For UDP mode the IP address 127.0.0.1 is also known as localhost and used when sending to a client on the same machine. The IP address of any other machine on the network may be given.”
</p>

<p>
To reach all machines within a local network, like a wifi router, use the address 192.168.x.255 with the Protocol set at UDP.
</p>
<pre class="code">  Example for a local net where the router address is 192.168.1.0:
  python VDRplayer.py Hakefjord.txt 192.168.1.255 10110 0.05 UDP
  Any receiving machine can then use IP address 0.0.0.0 and port 10110 in the connection properties</pre>

<p>
<strong>TCP</strong>  For TCP mode the IP address is the address of the machine running VDRplayer. It may be localhost or 127.0.0.1 if the client is running on the same machine.
</p>

<p>
If VDRplayer is running on its own machine then give the IP address: of that machine that other clients can reach (e.g. 192.168.1.6 assuming that is the address of the machine running VDRplayer.py).
</p>

<p>
The Port Number: 10110 is somewhat arbitrary but it is the “undocumented standard” for NMEA over IP and must match the client receiver port number. Any port number permitted by the local firewall will work. It is best not to use well known port numbers such as 80, 22, etc.
</p>

<p>
The time delay of 0.05 (50mS) is the delay between each line in the file.
</p>

<p>
<strong>UDP received</strong>  When adding a network connection for UDP receive there is no need to specify the IP address. The port is required but not the IP address. The sending end needs to specify both IP address and port number.
</p>

</div>
<!-- EDIT20 SECTION "NOTES" [34730-] -->
<!-- no cachefile used, but created /var/www/html/dokuwiki/data/cache/d/d1f2494201c8132da7a3586b5ff9b299.xhtml -->
</div>
</body>
</html>
